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(57) Abstract 

A system and method for securely and flexibly handling prepaid card transactions in a single store, chain of stores, or multiple 
independent stores or chains of stores. Point of sale terminals are programmed to read prepaid cards and contact a host computer that 
autorizes transactions. The host computer (6) accesses a database containing a list of all clerks authorized to use each terminal. In a 
preferred embodiment, three types of terminals are provided: activation terminals (3) that permit value to be added to prepaid card, clerk 
terminals (4) that permit value to be redeemed from, but not added to, prepaid cards, and manager terminals (2) mat are capable of adding 
or deleting a clerk from the list of clerks authorized to use a terminal. The system also permits a merchant or customer service provider to 
directly access the data base from a computer in a secure restricted manner. 
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Secure Flexible Prepaid Card System and Method 

FIELD OF THE INVENTION 

The present invention relates to prepaid card systems 
5 and, in particular, to a secure and flexible system and 
method for handling prepaid card transactions in a single 
store, chain of stores or multiple independent stores or 
chains of stores. 

10 BACKGROUND OF THE INVENTION 

Prepaid magnetic -strip cards have been used for years as 
payment for goods and services. Typically, prepaid card 
systems fall into two general classes. In one class, a value 
is stored in the magnetic strip on the back of the card and 

15 each time a card is used to purchase a good or service the 
stored value is decreased by the purchase amount. Prepaid 
cards used to pay for, for example, copies at copy machines 
typically fall into this first class. 

In the other class, a value is not stored on the card 

20 itself, but instead is stored in an account on a computer. 
The card typically contains information identifying the 
account. Prepaid phone cards are an example of this type of 
system. Prepaid debit cards offered by some department 
stores and other stores are another example. 

25 Prepaid debit card systems at department and other 

stores have typically required a major investment in hardware 
and software. For example, one known technique has been to 
implement a prepaid debit card system on top of an existing 
store credit card system. This technique involves creating a 

30 credit card account with a preloaded credit (i.e., the value 
of the prepaid debit card) and a zero dollar credit limit (so 
that the card cannot be used to charge more than the 
preloaded credit) . 

There remains a need however for a prepaid debit card 

35 system that can be implemented in stores and chains of stores 
that do not have the infrastructure to support a system in- 
house. There also remains a need for a prepaid debit card 



WO 00/50986 



PCT/US00/04654 



system that offers multi-level security features that will 
give merchants confidence that the cards are not used in a 
fraudulent manner and a need for a system that has the 
flexibility to exploit the many advantageous uses prepaid 
5 debit cards can have in business and marketing. 

SUMMARY OF THE INVENTION 
Briefly, the present invention provides a prepaid debit 
card system and method which is available to any merchant who 

10 has programmable point of sale terminals (such as those used 
to process credit card transactions). The point of sale 
terminals are programmed so that they can read information 
encoded on a prepaid debit card and contact a host computer 
at a systems headquarters. The host computer processes 

15 prepaid card transactions of preferably numerous merchants 
and stores information about the transactions in a flexible, 
secure database. 

The system provides multiple levels of security to 
prevent value from being added to a prepaid card in an 

20 unauthorized manner. First, only certain terminals are 

capable of adding value to a prepaid card and those terminals 
can be kept in a secured area. Second, a list of all clerks 
who are authorized to use each terminal is stored in the 
database, further preventing a clerk from initiating an 

25 unauthorized transaction. Third, only certain terminals, 
referred to herein as manager terminals, are capable of 
adding or deleting a clerk from the list of clerks authorized 
to use a terminal. Fourth, users who access the database 
directly by connecting to the host computer from another 

30 computer, instead of from a point of sale terminal, have a 
profile stored in the database specifying whether the user 
can add value to a prepaid card account, how much the user 
can add in a single transaction, and how much the user can 
add over a specified period of time, such as a day. In 

35 addition, the host computer limits each such user's access to 
the database to information regarding specific merchants and 
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the profile further specifies which portions of the 
merchants' information is accessible to the user. 

The system is also structured to exploit the use of 
prepaid cards as a business and marketing tool for merchants. 
5 For example, in a preferred embodiment of the invention, the 
database stores information necessary to implement a "buy ten 
get one free" type promotion and to implement a frequent 
buyer type promotion where cardholders are rewarded for the 
use of their prepaid cards. 
10 The present invention also provides a convenient and 

flexible mechanism for prepayment of a variety of services 
and products. One embodiment, described below, specifically 
provides a prepaid card system and method for payment of 
prepaid residential phone service. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a block diagram of the prepaid debit card 
system of a preferred embodiment of the present invention. 
Fig. 2 is a block diagram illustrating portions of the 
20 database used in an embodiment of the present invention. 
Fig. 3 is a block diagram illustrating additional 
portions of the database used in an embodiment of the present 
invention. 

Fig. 4 illustrates transaction types comprising an 
25 embodiment of the present invention. 

Fig. 5 is a flowchart illustrating an add or delete 
clerk operation initiated at a manager terminal. 

Fig. 6 is a flowchart illustrating an activation 
operation. 

30 Fig. 7 is a flowchart illustrating a redemption 

operation. 

Fig. 8 is a block diagram illustrating the services 
provided to a merchant by the host computer in a preferred 
embodiment of the present invention. 
35 Fig. 9 is a block diagram of the services provided to a 

cardholder in a preferred embodiment of the present 
invention. 
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Fig. 10 is a flowchart illustrating commission payment. 

Fig. 11 is a flowchart illustrating an activation 
operation of a prepaid residential phone card. 

Fig. 12 illustrates detail_codes for a prepaid 
5 residential phone card. 

Fig. 13 is a block diagram illustrating still additional 
portions of the database used in an embodiment of the present 
invention. 

10 DETAILED DESCRIPTION OF THE 

PREFERRED EMBODIMENTS 

Fig. 1 illustrates the basic hardware setup of a 
preferred embodiment of the present invention. In this 
embodiment, a merchant having one or more stores accepts 

15 prepaid debit cards as payment for the purchase of goods and 
services. Each store contains one or more manager terminals 
2, activation terminals 3 and/or clerk terminals 4. The 
preferred terminal is a Nurit 2080/2085 point of sale 
terminal manufactured by Lipman Electronic Engineering Ltd. 

20 However, any point of sale terminal or computer device with a 
prepaid card reading capability may be used if it can be 
programmed to perform the operations described herein. 

The manager, activation and clerk terminals may be 
physically identical and their designations refer only to the 

25 functions a terminal performs. As explained below, manager 
terminal 1 can add or delete a terminal operator (also 
referred to herein as a clerk) to the system, activation 
terminal 2 can add value to a prepaid card, and clerk 
terminal 3 can redeem value from a prepaid card. Manager 

30 terminal 1 may also perform the functions of the activation 
and clerk terminals 3 and 4; and activation terminal 3 may 
perform the functions of clerk terminal 4 . 

Each terminal is connected, preferably by a dedicated 
phone line 5, to host computer 6 in systems headquarters 7. 

35 Host 6 processes transactions initiated by terminals 2, 3 and 
4 and updates and maintains database 8, which is on central 
server 15. Database 8, described below, contains information 
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about merchants, terminals, users and transactions. Host 6 
and central server 15 are preferably industrial -grade Intel 
Pentium* II based computers running the Microsoft™ Windows NT 
Server operating system and the Microsoft™ SQL Server 
5 database backend program. In one embodiment of the present 
invention host computer 6 is a Compact Proliant 3000 server 
with dual Intel Pentium* II 450 MHz processors and central 
server 15 is a Compact Proliant 3000 server with a single 
Intel Pentium* II processor. Host computer 6 may be comprised 
10 of multiple computers in order to efficiently process 
numerous simultaneous calls from terminals 2, 3 and 4 in 
stores 1. 

Host 6 is also attached to one or more workstations 9. 
Workstations 9 are used, for example, by customer service 10 

15 to access and maintain information in database 8. They may 
be any computer capable of processing web-based documents. A 
customer 11 calling customer service 10 is first connected to 
an IVR (integrated voice response) unit 12 where the 
customer's request is handled in an automated fashion, IVR 

20 unit 12 passes the call to customer service 10 if the 

automated response does not address the customer's question. 

Host 6 is also connected to merchant computer 13 via 
phone lines, Internet, local or wide area network or other 
means. This enables the merchant to request and receive 

25 reports regarding prepaid card transactions, to review and 
update database 8, and to perform other operations. Merchant 
14 may also directly contact customer service 10, for 
example, to establish an account in the database 8. 

30 Database Overview 

Figure 2 illustrates the general structure of database 
8. Each box represents a table in the database and the 
contents of a box identify the fields of a record in the 
table. A line between two boxes indicates that the two 

35 tables have common fields, indicated by the endpoints of the 
line, over which they can be joined. As used herein, the 
tables are said to be "linked" on the common fields. The 
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tables themselves are preferably stored in multiple files 
with table entries for each merchant stored in files in 
directories uniquely associated with the merchant. 

Merchants table 21 contains general information about a 
5 merchant, such as when the merchant's merchants table entry 
was created (the receiptjdata field) , the types of payment it 
accepts (Visa/Master Card, American Express, prepaid cards, 
ATM cards, check verification, Diners Club, Discover, EBT 
(food stamps) , and other) (the visa, amex, prepaid_cards , 

10 atm, check_verify, diners, discover, ebt and other fields, 
respectively) , whether the merchant signed up for a payment 
and service program (the jnerchant_cluJb field) , whether the 
merchant's account has been cancelled (the cancelled field), 
its legal business name (the legal_businessname field) , its 

15 DBA (doing business as) name (the dba field) , its tax 

identification number (the tax_id field) , the name and phone 
and fax number of a contact person (the contact, 
contactjphone, and con tac t_f ax fields) , its physical and 
mailing addresses (the nine fields starting with the "phys_" 

20 and "/nail_ M prefixes) , its field of business (the sic_code 
field) and a bank account routing number and bank account 
number (the aba and accountjno fields) . It also contains a 
merchant identification number, merchant^id, which is 
assigned by the system and uniquely identifies the merchant, 

25 and a sales representative identification number (repaid) , 
which identifies the sales representative that sold the 
merchant the prepaid card system. The rec__id field contains 
a unique number assigned to each record in the table. 

Principals table 22 contains information about the 

30 principals of each merchant. This information may include 
the principal's name, driver license information, phone 
number, social security number, date of birth, address, 
length of time as principal and percent ownership (the 
legalname, drivers_license and lic_expdate, phone, ssn, 

35 datajof_birth, address, city state and zip, years, months and 
percentjownership fields) . It is linked to the merchant 
table on the merchant id field. Multiple principals table 
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entries may exist for each merchant. The principal_id field 
contains a unique number assigned to each principal. 

Rates table 24 contains information about the rates 
charged to a merchant for each of the various forms of 
5 payment accepted by the merchant. A rates table entry exists 
for each form of payment accepted by a merchant. The type of 
payment is provided in the type field. For prepaid cards, 
the merchant is charged, in one embodiment, a per item fee on 
each sale using a prepaid card, as specified in the 
10 merch _per_item field. Alternatively, a merchant may be 

charged a percentage of the sale price. Also, a merchant may 
be charged a fee for receiving a statement, as specified in 
the merch_statenient_fee field. A merchant may also receive a 
commission, specified in the merch_commission field, for 
15 certain types of transactions; for example, a merchant may 
receive a commission for a sale of a prepaid card. Rates 
table 24 also stores information regarding up to three levels 
of commissions to be paid to sales representatives who were 
involved in the sale of the prepaid card system to the 
20 merchant (repl_cowmission, rep2_commission and 

rep3_commission) . These values may be used to vary the 
default commission for a representative given in reps table 
23 described below. Rates table 24 is linked to merchants 
table 21 on the merchant_id field. The representatives are 
25 identified through the rep_id field in the associated 

merchant table entry. The id field contains a unique number 
assigned to each record in the table. 

Reps table 23 contains information about the sales 
representatives that sold the prepaid card system to a 
30 merchant. This information may include the representative's 
name and initials (the initials, firstname, lastname, and 
minitial fields) , business name {businessname field) , social 
security number (ssn field), hire and termination dates 
(hiredate and termdate fields) , address (address, city, state 
35 and zip fields) , phone, fax and email information {phone, fax 
and email fields), default commission rate (defaultcomm 
field) and a flag indicating whether a commission report is 
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sent to the representative (report field) . A reps table 23 
entry is linked to the merchants table on the repaid field. 
An entry in the reps table may also be linked, on the iso_id 
field, to another reps table entry, thus identifying a sub- 
5 representative. In the preferred embodiment, two sub- 
representatives may be entered for each representative, for a 
total of three representative and sub-representatives. The 
three correspond to the three levels of commissions in rates 
table 24. Any number of representatives and sub- 

10 representatives may be allowed in alternative implementations 
of the present invention. Each record in reps table 23 is 
also linked on the type field to the type_ id field in 
rep_type table 25. JRep_type table 25 identifies the type of 
sales representative (internal or external) in its 

15 description field. 

Terminals table 26 contains information about each 
terminal owned by each merchant. Multiple records in 
terminals table 26 may be associated with a single merchants 
table entry. The merchant_id field identifies the store 

20 where the terminal is located and provides a link to the 
store's entry in merchants table 21. The owner^id field 
identifies the owner of the store if, for example, the store 
is part of a chain. The millennium_jio field contains an 
identification number assigned to each terminal by the 

25 system. The jnanager_card field contains the manager card 
number for the terminal. A terminals table record is linked 
on the millennium__no field to possibly multiple records in 
terminaljpasswords table 27. Other information about each 
terminal may include identification numbers of various 

30 debit/ATM and credit card processors (the lynk_no, gensarjzo, 
visanet__no, buypassjno, and jnel!on_rio fields) , serial numbers 
and manufacturer/model information for the terminal, its 
pinpad and its printer (the serial_no, pinpad_sernum, 
pr inter _sernum, terminal_type, pinpad_type and printer_type 

35 fields) , the date the terminal was shipped to the customer 
(ship_date field), the version number of the terminal's 
software (version field) , a flag indicating whether use of 
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the terminal is password protected (i.e., limited to certain 
clerks as described below) (password field) , and whether a 
terminal is, e.g., leased or purchased (purchase.type field). 
The recjd field contains a unique number assigned to each 

5 record in the table. 

Terminal_passwords table 27 contains the passwords (or 
clerk numbers) of the clerks who are authorized to use the 
terminal identified in the millenniums field. The password 
field contains the password or clerk number. Multiple 
10 terminal_passwords table entries may exist for each terminals 
table entry. The rec_id field contains a unique number 
assigned to each record in the table. 

Figure 3 illustrates other tables in database 8 . Cards 
table 41 contains an entry for each prepaid card that is 
15 distributed to a merchant. The Pin field contains a unique 
identifier for each prepaid debit card. This identifier is 
also encoded in the magnetic strip on the back of the card 
(or printed on or otherwise associated with a card) . The 
Produced field links the entry to an entry in Products 
20 table 42, which identifies the type and characteristics of 
the prepaid card. The Control_no, Batch, and Lot fields 
provide tracking information for each card. The Disabled 
field indicates whether the card has been disabled. The 
Balance field specifies the current cash balance available on 
25 the prepaid card. Other fields in Cards table 41 are 

discussed below. 

Products table 42 contains information about groups of 
cards. The Id field contains a product identification 
number. The Description field identifies the type of the 
30 cards in the group (e.g., prepaid debit card, prepaid phone 
card, etc.). The Disabled field indicates whether all the 
cards in the product are disabled. The Pin_count field 
contains the number of cards in the group and the 
A ctivation_count contains the number of cards that have been 
35 activated. The Usage.amount field contains the total amount 
debited from all the cards in the group and the 
Ac tivation_amount contains the total amount of value added to 
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the cards in the group. The Prompt field indicates the 
language that prompts from the host computer should be in. 
The Expire_date field contains the date on which all cards in 
the group expire. The Program_id field identifies the 
5 software program that is associated with the cards in the 
group; for example, one program may be run for a specific 
group of prepaid debit cards and a different program may be 
run for a different group of cards. Finally, the 
Rechargeable field indicates whether the cards in the group 
10 may be recharged (i.e., whether value may be added to a 
card) . 

Transactions table 43 contains information about all 
transactions processed by the system. The rec_id field is a 
unique identification number assigned to each record in the 

15 table. The Date time field specifies the date and time of a 
transaction. The Pin field specifies the pin number of the 
prepaid card used in the transaction and provides a link to 
the entry for that card in cards table 41. The Type field • 
specifies the type of the transaction. These types include 

20 (1) original activation, (2) recharge, (3) return, (4) CS 
(customer service) credit, (5) test transaction, and (6) 
redemption, as shown in Figure 4. The test transaction type 
is used to test the system. The other types of transactions 
are described below. The Account_id field specifies the 

25 terminal number of the terminal on which the transaction was 
performed and provides a link to the entry for that terminal 
in terminals table 26 -- Account_id in transactions table 43 
has the same meaning as millennium_no in terminals table 26. 
The Amount field contains the amount of the transaction, if 

30 applicable. The Clerk field contains the password (or clerk 
number) of the clerk (or' other user) that handled the 
transaction; it has the same meaning as the password field in 
■ terminal passwords table 27. The Ach_flag and Ach_datetime 
fields indicate whether the system has processed the 
35 transaction against the merchant's account and, if so, when. 
The Client and Port fields indicate the host computer that 
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processed the transaction, if there is more than one host, 
and the port number on the host computer that was used. 

A person skilled in the art will recognize that there 
are many different ways of configuring the tables in database 
5 8, and the present invention is not limited to the 

configuration shown herein. Different and/or additional 
tables may be used and different and/or additional fields may 
be used in the tables. 

Additionally, tables and fields may be added to database 

10 8 to support, for example, a prepaid phone card system. In 
this case, rates table 24 could, for example, contain rate 
and commission information regarding phone card plans, cards 
table 41 and products table 42 could contain rateplan 
information, and additional tables could be added that stored 

15 inbound and outbound call information for each card and call 
routing and language information for each prepaid phone card 
product . 

Manager Terminal 

20 Manager terminals are, in one embodiment of the present 

invention, the only terminals at which clerks or other 
terminal operators can be added or deleted from database 8. 
For added security, the add/delete function can only be 
activated after a valid manager card is swiped through the 

25 terminal. Manager cards are provided by Lipman Electronic 
Engineering, Ltd. for each Nurit terminal to enable 
restricted access to special terminal features that may be 
defined by purchasers of the terminals. The add/delete clerk 
function is not a feature of the standard Nurit terminal. 

30 The add/delete clerk function is illustrated in Figure 

5. In step 70, a manager or authorized clerk swipes a 
manager card through the manager terminal. In step 72, the 
manager then selects an add or delete clerk operation on the 
terminal. In step 74, the manager enters a clerk number (or 

35 password) . In step 76, the terminal then calls host 6 in 
systems headquarters 7 and sends it a message containing a 
transaction code specifying either an add clerk or delete 
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clerk transaction, the terminal's identification number, the 
clerk number, and manager card identification information. 

In step 78, host 6 examines terminals table 26 in 
database 8 and determines whether the received terminal 
5 number is valid — i.e., whether an entry exists for it in 
the database. If it is valid, then host 6, in step 80, tests 
whether a valid manager card was used. If the manager card 
is valid, step 86 is executed. Otherwise, if either the 
terminal number or manager card is invalid, step 82 is 

10 performed in which host 6 sends a message to the terminal 
indicating that the transaction is not authorized. 

In step 86, the received clerk number is added or 
deleted, depending on the transaction code, to or from the 
database. For an add clerk transaction, a terminal_passwords 

15 entry is created, with the password being the received clerk 
number (or password) , for each terminal in the same store as 
the calling terminal (i.e., each terminal whose terminals 
table entry has the same jnerchant_id as the calling 
terminal) . For a delete clerk transaction, every entry in 

20 terminal_passwords table 27 whose millenniumjno identifies a 
terminal in the same store as the calling terminal and whose 
password is the same as the received clerk number (or 
password) is deleted. 

In alternate embodiments, different or additional 

25 information may be transmitted from the terminal to host 6. 
For example, the manager or authorized clerk may also specify 
a specific terminal number or set of terminal numbers that a 
clerk is to be added to or deleted from. Also, a software 
version number may be transmitted so that the host can check 

30 it against the version field of the calling terminal's entry 
in terminals table 26, as an added verification of the 
calling terminal. 

Prepaid Debit Card 
35 In one embodiment of the invention, each prepaid debit 

card has a magnetic strip on the back having data in the 
following format: 
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account number, field sep, yymm, use code, filler 

where account number is preferably a long random number 
assigned to the card; field sep is a field separator, such as 
5 - = ■, yymm is the year and month the card expires; use code is 
the American Bankers Association code specifying where 
geographically the card can be used (a use code of 101 means 
the card can be used anywhere) ; and filler is filler for 
possible future use. 

10 An entry in cards table 41, described above, is created 

for each card that is manufactured and shipped to a merchant. 
Preferably, a card is initially given a balance of $0 (i.e., 
the Balance field of its Cards table entry is set to 0) , 
though a merchant may request that the accounts be preloaded 

15 with some value for, for example, a promotion. 

Art-ivation Terminal 
Activation terminals 3 (and manager terminals 2) contain 
software that enable value to be added to a prepaid card. 
20 Clerk terminals 4 do not contain this software and therefore 
a clerk without access to an activation or manager terminal 
cannot perform this function. 

Figure 6 is a flowchart illustrating the process of 
adding value to a prepaid card from an activation terminal. 
25 In step 90, a clerk swipes a customer's prepaid debit card in 
an activation (or manager) terminal. The terminal then 
prompts the clerk for the type of transaction and in step 92 
the clerk selects an activate (add value) transaction. The 
clerk then enters the amount to be added to the prepaid card 
30 and his or her clerk number in steps 94 and 96. 

In step 98, the terminal connects to host 6 via, in one 
embodiment, an asynchronous modem connection, and transmits a 
message having the following format: 

35 <stx>,«BSSAGE<etxxlrc> 
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where <stx> is a start of text indicator, <etx> is an end of 
text indicator and <lrc> is linear redundancy check, which is 
calculated from the body of the message and used as a simple 
error correcting mechanism. If the <lrc> calculated by the 
5 host does not equal the <lrc> sent by the terminal, the host 
sends a <nak> (negative acknowledge) character to the 
terminal and the terminal will resend the message. This is 
repeated up to three times before the host sends an <eot> 
(end of transmission) character and disconnects the phone 
10 line. 

If the <lrc> calculated by the host matches the one sent 
by the terminal, the host processes the body of the message, 
MESSAGE. The MESSAGE sent by the terminal has the following 
comma delimited fields: 

15 

[transaction type] , [terminal number] , 

[pin number) , [amount] , [clerk number] 

where transaction type is the type of the transaction, in 
this case an activate transaction, terminal number is the 
20 terminal number of the calling terminal, pin number is the 
account number encoded on the swiped prepaid card, amount is 
the amount to be added to the account associated with the 
swiped prepaid card, and clerk number identifies the clerk. 
In step 100, host 6 determines the type of transaction 
25 from the transaction type field of the received message. If 
it is an activation, the host then performs step 102 in which 
it determines whether the received terminal number is valid 
(whether it, for example, has a valid entry in terminals 
table 26) . If it is valid, the host determines, in step 103^ 
30 whether the clerk is authorized to use the terminal. This is 
done by searching the terminal_passwords table 27 for an 
entry having millennium_no set to the received terminal 
number and password set to the received clerk number. If the 
clerk is authorized to use the terminal, the host then 
determines, in step 106, whether an entry exists in cards 
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table 41 for a card with the received account number. If it 
does then processing proceeds to step 108. 

If the results of any of the tests in steps 102, 103 or 
106 are negative (i.e., the terminal is invalid, the clerk is 
5 not authorized to use the terminal, or the received prepaxd 
card account number is invalid) , step 104 is performed xn 
which the host sends a message to the terminal indicatxng 
that the requested transaction has been denied. 

Otherwise, in step 108 the host calculates the new 
10 balance for the card by adding together the current balance 
for the prepaid card from the Balance field in the card's 
cards table entry and the received activation amount. It 
then sends a message to the terminal stating that the 
requested transaction is authorized (i.e., -0K-) and what the 
15 new card balance is. The message is in the same message 

format as the one earlier sent from the terminal to the host 
- < s tx>,MKSSAGE<etxxlrc>. The terminal performs an <lrc> 
check on the message and, if the message is valid, the 
terminal sends an <ack> (positive acknowledge) character to 
20 the host. Otherwise, the terminal sends a <nack> character 
to the host, and the host attempts to resend the message, 
the host fails after three attempts, it sends an <eot> 
character and disconnects the phone line in step 112 . 

in step 110, the host tests whether it received an <ack> 
25 character back from the terminal. If it did, it hangs up the 
call in step 114 and updates the cards table entry for the 
received card number with the new balance. The host also 
creates an entry in transactions table 43. If this was the 
first time value was added to the card, the transactxon type 
30 is set to indicate an original activation; otherwise, the 
transaction type is set to indicate a recharge. 

If the host did not receive an <ack> character, but 
. instead received a <nack> character, two more attempts are 

made to send the message from the host to the terminal and xf 
35 those fail too, the host hangs up in step 112 and does not 
update the cards table. 
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Clerk Terminal 
Clerk terminals 4 (as well as activation and manager 
terminals 2 and 3) contain software for redeeming value from 
a prepaid debit card and returning a prepaid debit card. A 
5 redemption is performed, for example, when the card is used 
to purchase goods or services. 

Figure 7 illustrates the process of redeeming value from 
a prepaid card. The first six steps in the process are 
similar to those for the activation process described above. 
10 The clerk swipes a customer's prepaid card in a terminal in 
step 130, and selects a redeem operation at his or her 
terminal in step 132 . The clerk then enters the amount to be 
redeemed in step 134 and his or her clerk number in step 13 6. 
The terminal then connects, via, for example, a dial-up 
15 connection, to host 6 in step 138, and sends a message having 
the same format as that for an activation except that the 
transaction type field specifies an redemption transaction. 

In step 140, the host determines the type of the 
transaction and, if the transaction is a redemption, performs 
20 step 142. In step 142, the host determines if the call is 
from a valid terminal, for example, by checking whether a 
terminals table entry exists for the received terminal 
number. If the terminal is invalid, the host sends, in step 
144, a message to the terminal indicating that it is invalid 
25 and hangs up (step 162) . If the terminal is valid, the host 
next determines, in step 148, whether the clerk is authorized 
to use the terminal. Again, this is done by checking if 
there is a terminal_passwords table entry in which the 
millennium_no field is set to the received terminal number 
30 and the passwords field is set to the received clerk number. 
If the clerk is authorized to use the terminal, the host then 
determines, in step 150, whether the prepaid debit card 
exists in database 8 by searching Cards table 41 for an entry 
whose Pin field is the same as the received card account 
35 number. If the card exists, and is not disabled, then step 
154 is executed. If steps 148 or 150 determine that the 
clerk is not authorized to use the terminal or the prepaid 
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card is not valid, the host sends, in step 152, a message to 
the terminal that the transaction is declined and hangs up 
(step 162) . 

In step 154, the host compares the received redemption 
5 amount to the current balance stored in the cards table entry 
for the card to determine if there is sufficient funds. If 
there is not sufficient funds, the host sends a message to 
the terminal indicating the current balance and that there is 
not sufficient funds for the transaction (step 156) and 

10 terminates the phone connection (step 162) . If there is 
sufficient funds, the host sends a message to the terminal 
indicating the available balance left after the transaction 
and that the transaction is approved (step 158) . The host 
then waits for a positive acknowledgement from the terminal 

15 (step 160) and if it does not receive one after three 

attempts to transmit the message to the terminal, it hangs up 
(step 162) . 

If the host receives a positive acknowledgement it then 
updates the cards table entry for the received account number 

20 by debiting the received redemption amount from the balance 
field and adding the redemption amount to the total_usage 
field (step 164). The host also creates, in step 164, a 
transactions table entry, setting the Pin field to the 
received account number, the Type field to indicate a 

25 redemption, the Accounted field to the received terminal 

number, the Amount field to the amount of the redemption, the 
ClerJc field to the received clerk number, and the Ach_flag 
field to 0, indicating that commissions on the redemption 
have not yet been processed. The host then hangs up in step 

30 162. 

The process for a card return is similar to the 
processes described above. The clerk swipes the card, 
presses the appropriate keys on the terminal for a return 
transaction and enters his clerk number. The terminal then 
35 calls the host computer, which verifies that the calling 
terminal is valid, that the clerk is authorized to use the 
terminal and that the card is valid. The host then sends a 
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message to the terminal indicating the remaining card balance 
and, waits for a positive acknowledgement from the terminal. 
If it receives it, the host updates the cards table entry for 
the prepaid card, setting the balance to zero. It also 
5 creates a transaction table entry, setting the transaction 
type field to indicate a return. 

All terminals also have software for producing batch 
reports that itemize and total all transactions performed at 
a terminal over a period of time. 

10 

Commission Payment 
Transactions table 43 is periodically scanned by host 
computer 6, preferably once a day, in order to collect 
commissions from the merchants for prepaid card transactions. 
15 A flowchart of this process is illustrated in Figure 10. 

In step 250, the host computer sets the current entry to 
the first entry in the transactions table. Step 252 
determines whether the transaction is a redemption by 
examining the entry's type field. If it is, step 254 is 
20 performed which determines whether the transaction has 

already been processed by examining the ach_flag field. If 
either the transaction is not a redemption or the transaction 
has already been processed, then processing continues at step 
262. 

25 Otherwise, step 256 is performed, in which the host 

computer determines the amount of commission owed by the 
merchant. This involves finding the rates table entry 
associated with the transaction by tracing the links from 
transactions table 43 to terminals table 26, then from 

30 terminals table 26 to merchants table 21, and from merchants 
table 21 to rates table 24. In step 258, the commission is 
withdrawn from the merchant's bank account using the routing 
code found in the aba_no field of the corresponding terminals 
table entry. 

35 In step 260, commissions owed to sales representatives 

and sub-representatives are calculated using the information 
in the corresponding rates table entry found above and the 
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corresponding reps table entry, which is found by following 
the link from the corresponding merchants table entry to reps 
table 23. 

In step 262, the current entry is set to the next 
5 transactions table entry. Step 264 tests if the end of the 
table has been reached. If it has, the process is over (step 
266); otherwise the process returns to step 252. 

Merchant Services 

10 In a preferred embodiment of the invention, a merchant 

is provided direct access to the information stored in 
database 8, as illustrated in Figure 8. 

In step 180, a user at, for example, merchant computer 
13 (in Figure 1) connects to host computer 6 via, e.g., a 

15 dial-up connection, a hardwired connection or the Internet. 
For each user who may access host computer 6 in this manner, 
a users table entry must first be created. 

Users table 28 is shown in Figure 2. The initials field 
contains the user's initials. The fullname field contains 

20 the user's full name. The password field contains a password 
for the user. The lastJLogin field contains the date and 
time the user last used the system. The credit field 
specifies whether the user is authorized to issue credit 
(i.e., add value) to a prepaid card. The credit field 

25 specifies whether a user can issue a credit. The creditlimit 
field specifies the maximum amount of credit the user is 
authorized to issue per transaction. For example, a user may 
be authorized to credit no more than $5 at a time. The 
dailylimit field specifies the maximum amount the user is 

30 authorized to issue per day. The reps, merchants, and comms 
fields specify whether the user is authorized to access the 
reps, merchants and rates tables, respectively. The users_id 
field contains a unique number assigned to each record in the 
table. 

35 In step 182, host computer 6 verifies the user's access 

rights by, for example, prompting the user for his or her 
initials and passwords, looking up the users table entry for 
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the user having the entered initials and comparing the 
entered password to the password field of that users table 
entry. Alternatively, a user's access rights may be verified 
based on the phone number the user is calling from using 
5 ANI (automatic number verification) or Caller ID to identify 
the originating phone number --or the Internet IP address of 
the user, if the user is accessing the host via the Internet. 
Other verification techniques may also be used. 

In a preferred embodiment of the invention, operating 

10 system features on the host computer are used to limit a 
user's access to the database, permitting a user to access 
only the data of a specific merchant or group of merchants. 
For example, in Windows NT, a user's profile maintained by 
the operating system can be used to limit access by the user 

15 to files only in specified directories. Accordingly, on a 
Windows NT system, the tables in database 8 can be stored in 
multiple files, with each file containing data regarding one 
merchant and stored in a directory that only contains files 
regarding that merchant. A user's access to information 

20 about specific merchants can then be implemented using the 
directory restriction feature. 

Returning to Figure 8, if access is denied in step 182, 
the connection is terminated in step 184. Otherwise, the 
user may choose either to access the raw data for the 

25 merchant directly (step 186) or to access the data through a 
browser-based interface 188 on the host computer. The former 
option would typically be chosen by users who have their own 
software for querying the data and generating reports. In 
either case, merchants are provided with real-time 

30 information about all transactions processed by host computer" 
6. 

Interface 188 provides at least the following features: 
form queries 190, report generator 192 and card specific 
functions 194. 

35 Form queries 190 are forms which a user fills in to 

perform various queries on database 8 . 
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Report generator 192 generates daily reports 196, weekly 
reports 198 and monthly reports 200, which itemize and/or 
summarize prepaid card transactions for the merchant over the 
relevant time period. Reports may present information on a 
5 per terminal or per card basis, if desired. Also, reports 
may be sent to the merchant on a periodic basis by, for 
example, fax or mail. Reports for chains of stores, for 
example in a franchise, may be consolidated so that 
activations and redemptions among the various stores in the 

10 chain may be reconciled. For example, if over the relevant 
time period store A in a chain activated a card for $10 and 
did not redeem value from a card and stored B redeemed $5 but 
did not receive any money to activate a card, then $5 should 
be transferred from store A to store B, since store B gave 

15 the cardholder $5 worth of goods or services, but did not yet 
receive any payment for it. 

Card specific functions 194 allow a merchant to directly 
service customers, if desired. Merchants may prefer however 
to have customers use customer service 10 in systems 

20 headquarters 7, as described below. Card- specific functions 
include looking up a balance on a prepaid card 202, issuing 
credit 204, and adding to, or otherwise accessing, 
information in a notes table, which is a log of cardholder 
requests and complaints. 

25 As a security feature, a user's ability to issue credit 

is limited by the information in the user's user table entry. 
As explained above, the user table entry specifies whether a 
user may issue credit (the credit field) , the amount of 
credit that may be issued in a single transaction (the 

30 creditlimit field) and the amount of credit that may be issue 
in a single day (the dailylimit field) . A credit issued 
through interface 188 (or customer service 10) generates a 
transactions table entry with the transactions type 
preferably set to indicate a CS (customer service) credit. A 

35 credit is also reflected in the cards table entry for the 

prepaid card, with the Balance and Total_credits fields being 
incremented by the credited amount. 
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Also, a user's ability to access the reps table, 
merchants table, rates table is restricted based on the 
contents of the reps, merchants and conuns fields. 

5 Cardholder Customer Service 

A cardholder who has questions about his or her prepaid 
card may call customer service, as illustrated in Figure 9. 
In step 220, a cardholder calls customer service and is 
connected to an IVR (integrated voice response) unit in step 

10 222. The IVR unit handles certain requests in an automated 
fashion, such as a request to get the balance on a prepaid 
card 224 or to find the closest location accepting the 
cardholder's card 226. To get the balance, the IVR unit 
prompts the cardholder to enter the account number of the 

15 card and then looks the information up in cards table 41. To 
get the closest location, the IVR unit preferably determines 
the cardholder's current location based on the originating 
telephone number, which is determined using for example ANI 
or Caller ID. 

20 If the cardholder desires other services, the call is 

connected to a customer service representative 228. The 
customer service representative can for example provide 
information on past transactions 230, issue credits (if 
authorized to do so) 232, and add notes to the notes table 

25 234. Each customer service representative has an entry in 
users table 28 and is provided access to database 8 'in the 
same manner as other users. A customer service 
representative may have authorization to examine the data of 
multiple merchants. 

30 

Card Uses 

The prepaid card system of the present invention 
provides the flexibility to implement many special features. 
For example, a "buy 10 get 1 free" type promotion can be 
35 implemented by adding a nuin_times_used field to cards table 
41, which contains the number of times a card has been used 
for a redemption. When a card is used for a transaction, the 
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host computer can then include in a message to the terminal 
that the cardholder is, for example, entitled to one free 
product if the card was previously used ten times, two free 
products if the card was previously used twenty times, etc. 
5 If the cardholder chooses to accept a free product, the 
num_times_used field is decremented by ten. Of course, any 
number of previous uses may be used and any bonus or prize 
may be substituted for a free product. For example, a 
cardholder may be given discounted products instead of free 
10 products or the cardholder may have value added to his or her 
card . 

Similarly, a frequent user rewards program, in which a 
cardholder earns points towards free or discounted products 
or other prizes, can be implemented by adding a 

15 redeemedjpoints field to cards table 41. For example, each 
dollar spent may be considered a point toward a bonus or 
prize. The Total_usage field in cards table 41 then 
corresponds to the total number of points a cardholder has 
earned and the redeemed ^points field would contain the total 

20 number of points a cardholder has already cashed in. The 
Totaljasage minus the redeemed ^points in this example gives 
the currently available points. 

The prepaid cards may also be conveniently used to serve 
various business functions. For example, a prepaid card may 

25 be used as a store credit voucher for returned items, instead 
of the slips of paper that are now typically used. They may 
also be used as a store credit voucher even without a return, 
for example, as a grand opening promotion or other promotion. 
The prepaid card system of the present invention is not 

30 limited to the uses and the specific implementations 
described above. 

Pre paid Re sidential Phone Cards 
An embodiment of the present invention for paying for 
35 prepaid local phone service is illustrated in Figures 11 
through 13 . 
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Prepaid local phone services are used by customers who, 
because of credit problems or other reasons, do not qualify 
for regular phone service in which bills are sent typically 
monthly. In known such services, the customer must go each 
5 month to a vendor associated with the service provider and 
prepay the bill for the following month. For an initial 
activation of the service, the vendor must get required 
information from the customer, such as the customer's name, 
address and types of services desired (e.g., call waiting, 

10 caller ID, call forwarding, etc.) and communicate this 

information to the service provider. Each subsequent month, 
when the customer prepays for the next month, the vendor must 
communicate payment information, as well as any changes in 
requested services, to the service provider. This process is 

15 burdensome to some vendors. 

This embodiment of the present invention simplifies and 
automates the above process. Briefly, for an initial 
activation, the vendor provides the customer with a prepaid 
card, as described above, swipes the card in a terminal and 

20 enters the amount of money provided by the customer, 

information regarding the desired services and the vendor's 
clerk number. The terminal then calls the host computer, 
which verifies the clerk number and that the received amount 
is sufficient. The customer later directly calls the service 

25 provider (e.g., using a service provider's toll free number), 
provides the account number on the prepaid card and provides 
the required account set-up information. For subsequent 
payments, the vendor swipes the customer's card at the 
terminal (or enters the customer's phone number if the 

30 customer does not have the card) and enters the amount of 
money provided by the customer, information regarding the 
desired services and the vendor's clerk number. The terminal 
again calls the host computer, which again verifies the clerk 
number and that the amount of money provided is sufficient. 

35 Figure 11 illustrates the activation process for this 

embodiment (i.e., adding value to a prepaid card account) in 
more detail. In step 300, the vendor swipes a customer's 
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prepaid card or enters the customer's home phone number. The 
vendor then selects an activate transaction (step 302) and 
enters the amount of money provided by the customer (step 
304) and the vendor's clerk number (step 306). Next, the 
5 vendor enters a product code, indicating the services the 
customer wants to purchase (step 308) . In one embodiment 
this code is a sequence of two digit numbers, each number 
indicating a service. Examples of product codes for a 
prepaid residential phone card are shown in Figure 12. 
10 In step 310, the terminal connects to host 6 via, in one 

embodiment, an asynchronous modem connection, and transmits a 
message having a format similar to that described above in 
connection with Figure 6 except that the clerk number field 
is divided into two fields, as follows: 



15 



[clerk number] | [product code] 



where clerk number identifies the clerk and product code is 
the entered product code. The host computer then processes 

20 the received message as in Figure 6, first determining 

whether the transaction type is an activation (step 312) and 
then determining whether the call is from a valid terminal 
(step 314) , whether the clerk is authorized to use the 
terminal (step 316) and whether the prepaid card used in the 

25 transaction has an entry in cards table 41 (step 318) . In 
this embodiment, cards table 41 will also contain a phone 
field, identifying the phone number associated with the card, 
if one has been assigned, so that cards table 41 can^ be 
searched both on a received card pin number or a received 

30 phone number. If the terminal is not valid, the clerk is not 
authorized or the card is not in the database, the host sends 
a message to the terminal indicating that the requested 
transaction is denied (step 330) and hangs up (step 322) . 
Otherwise, step 324 is performed. 

35 In step 324, the host computer determines the price of 

services specified in the product code. First, the product 
table entry associated with the card is found via the link 
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between the product_id field of the cards table entry and the 
id field of an entry in products table 42 l Next, for each 
two-digit subcode in the received product code, the host 
locates an associated product_details table entry. The 
5 format of product_details table 372 is shown in Figure 13. 
The rec_id field is a unique identifier for each record in 
the table. The detail_code field is a code identifying a 
service/product, such as those shown in Figure 12. The 
amount field specifies the price of the service. The 
10 description field provides a description of the service. The 
product_id field provides a link to the id field of an entry 
in products table 42 (shown in Fig. 2) . A products table 
entry may be linked to multiple product_details table 
entries. The host computer then sums the price of each 
15 service/product specified in the received product code. 

In step 326, the host computer determines if the card's 
balance specified in the balance field of the located cards 
table entry plus the received amount is sufficient to pay for 
the services/products specified in the received product code. 
20 If it is not, the host sends a message to the terminal 

indicating that there is not sufficient funds and specifying 
the amount required for the requested transaction (step 328) 
and hangs up (step 320) . Otherwise, the host sets the 
balance field of the cards table entry to the new balance and 
25 sends a message to the terminal stating. that the transaction 
is authorized and what the new card balance is (step 332) . 
The host then checks if the terminal positively acknowledges 
receipt of the message (step 334). 

If a positive acknowledgment is received, the host 
30 computer hangs up (step 336) and, in step 338, updates the 
cards table entry with the new balance and creates a 
transactions table entry. In this embodiment, each 
transaction table entry is linked to possibly multiple 
transact ion_details table entries, which are also created at 
35 this time. The format of transaction_details table 370 is 
shown in Fig. 13. The rec_id field is a unique 
identification number assigned to each entry in the table. 



- 26 



WO 00/50986 



PCT/US00/04654 



The transaction_id field links the entry to an entry in 
transactions table 43. The prctduct_detail__id field links the 
entry to an entry in product_de tails table 372. The 
Export^Status field, as explained below, is set to 0 before 
5 the transaction has been posted for retrieval by the phone 
provider and 1 after the transaction has been posted. The 
AcknowldegeJDate field indicates the date the phone provider 
has processed the transaction. For overcharge transactions 
received from the phone provider, which are described below, 
10 the amount field is set to the amount of the overcharge and 
the AcknowledgeJDa te is set to 3 after the transaction is 
processed. 

If a positive acknowledgment was not received after 
three attempts, the host hangs up and does not update the 

15 database, (step 322) . 

Periodically, preferably every minute, host computer 6 
scans transaction table 43 for transactions involving 
residential phone cards. For each such transaction, the host 
computer posts the transaction information and the balance on 

20 the associated card and then sets the card's balance to zero 
and changes the Export_Status field of the associated 
transact ion_de tails entries^ from 0 to l. The information is 
posted such that the prepaid residential phone provider can 
retrieve it using, for example, a computer via an Internet or 

25 other connection. The residential phone provider then 

processes the transaction and contacts, again for example via 
a computer connection, the host computer which in turn sets 
the Acknowledge_Date field in the transaction_details entry 
for the transaction. Also, if the customer's balance 

30 exceeded the amount needed for the transaction, the provider 
sends overpayment information to the host computer and the 
host computer creates a transactions table entry, and an 
associated transaction_details entry, for the customer. In 
this case, the productjdetail_id field of the 

35 transaction_de tails entry is linked to a product_details 
table entry for an Overpayment. The amount of the 
overpayment is stored in the amount field of the 
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transaction_details table. When the host computer 
periodically scans the transactions table, it processes 
overpayment transactions by crediting the customer's card 
balance and setting the Export_Status field of the associated 
5 transaction_de tails table entry to 2. 

For an initial activation transaction, the customer, 
after prepaying for the service at a vendor and receiving his 
or her residential phone card, calls the phone provider (from 
a payphone or other phone) and provides the card number and 

10 certain required information, such as his or her address. 
The provider then contacts host computer 6 using any of the 
techniques discussed above (for example, through customer 
service 10, using its own computer to directly connect to 
host 6, or using a terminal) and provides the customer's card 

15 number. The host computer then verifies that there is an 
initial activation transaction associated with the card 
number in the transactions table and that the card has a 
balance. If both items are verified, the host computer 
reports the available balance and the services/products sold 

20 to the customer. It then sets the Acknowledge_Date field in 
the associated transaction_detail table entries. If both 
items are not verified, the host computer reports that the 
card is not found or that it has no balance. 

25 In this disclosure, there is shown and described only 

the preferred embodiments of the invention. It is to be 
understood that the invention is not limited to the 
particulars disclosed and extends to all equivalents included 
within the scope of the claims. For example, although 

30 particular data structures and algorithms were shown and 
described, other data structures and algorithms may 
equivalently be used. Moreover, the invention is not limited 
to particular types of hardware (computers, electronic 
device, etc.). For example, manager, activation and clerk 

35 terminals may be any electronic or microprocessor-based 
device that performs the required functions; connections 
between devices, such as the terminals and host computer, may 
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be any type of connection that permit the devices to 
communicate be it by telephone lines, wireless 
communications, local or wide area networks, or otherwise; 
and any device shown as a single unit may be implemented as 
5 multiple units (for example, multiple computers may comprise 
host computer 6) and multiple units may be combined into a 
single unit. 
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What is claimed is: 

1. A prepaid card system comprising: 

a. one or more prepaid cards each having an associated 
5 account number; 

b. at least one activation terminal at which value can 
be added to the one or more prepaid cards; 

c. at least one clerk terminal at which value can be 
redeemed from, but not added to, the one or more 

10 prepaid cards; 

d. a host computer connected to the at least one 
activation terminal and the at least one clerk 
terminal ; and 

e. a database that can be accessed by the host 
15 computer wherein the database stores 

i) for each of the at least one activation and 
clerk terminals, information regarding each 
clerk authorized to use the terminal; and 

ii) for each of the one or more prepaid cards, a 
20 current balance associated with the prepaid 

card. 

The system of claim 1 further comprising at least one 
manager terminal wherein: 

a. the database further stores, for each of the 
manager terminals, information regarding each clerk 
authorized to use the manager terminal; and wherein 

b. the information regarding each clerk authorized to 
use each of the activation, clerk and manager 
terminals can be modified from the manager 
terminal . 

3 . The system of claim 1 further comprising a second 

computer connected to the host computer wherein the 
35 database further stores information regarding access 

rights of users of the second computer to information in 
the database, including, for each user, 
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a. whether the user may increase the current balance 
associated with each of the one or more prepaid 
cards ; 

b. an amount the user may add to the current balance 
associated with at least one of the one or more 
prepaid cards in a single transaction; and 

c. a total amount the user may add to the current 
balance associated with at least one of the one or 
more prepaid cards over a specified period of time. 

4. The system of claim 1 wherein the database further 
stores for each terminal information regarding a 
merchant that owns the terminal . 

15 5. The system of claim 4 wherein at least two terminals in 
the database are owned by different merchants. 

6. The system of claim 1 wherein the database further 
stores transaction information regarding each 

20 modification to the current balance associated with at 

least one of the one or more prepaid cards, the 
transaction information comprising: 

a. an identification of the terminal at which the 
transaction was initiated, 
25 b. an identification of the clerk who initiated the 

transaction; 

c. an identification of the prepaid card whose current 
balance was modified; 

d. an amount of the transaction; and 
30 e. a type of the transaction. 

7. The system of claim 6 wherein the database further 
stores merchant information comprising: 

a. a list of terminals associated with a merchant; 
35 b. a list of sales representatives entitled to 

commissions for transactions occurring at terminals 
associated with the merchant, 
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c. information regarding commissions owed to the sales 
representatives on the list of sales 
representatives and a commission owed to an 
operator of the host computer, and 
5 d. information identifying a bank account number from 

which commissions are to be paid. 

8 . The system of claim 7 wherein the transaction 
information further comprises, for each transaction for 

10 which a commission is owed, information regarding 

whether the commission has been paid from the merchant's 
bank account. 

9. The system of claim 5 wherein the database is structured 
15 such that information relating to a first merchant is 

stored in a different directory from information 
relating to a second merchant, 

10. The system of claim 9 wherein a user at a merchant 
20 computer can be connected to the host computer, and 

wherein the host computer limits the user's access to 
the database to information regarding one or more 
specific merchants. 

25 11. The system of claim 10 wherein the merchant computer 
connects to the host computer via the Internet. 

12 . The system of claim 1 wherein the database further 
stores, for each of the one or more prepaid cards, the 

30 number of times the card has been used. 

13 . The system of claim 1 wherein the database further 
stores, for each of the one or more prepaid cards, a 
bonus point total derived from the use of the card and a 

35 redeemed point total indicating then number of bonus 

points that have been redeemed. 
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14 . The system of claim 13 wherein the bonus point total is 
the total dollar amount of transactions in which the 
card was used to purchase goods and services. 

5 15. A method of processing prepaid card transactions 
comprising the steps of: 

a. reading a prepaid card, including identifying 
information, at an activation terminal; 

b. entering at the activation terminal a value to be 
10 added to the prepaid card; 

c. sending to a host computer (i) information 
identifying the prepaid card, (ii) the value to be 
added to the prepaid card, and (iii) identification 
information associated with a person operating the 

15 activation terminal; 

d. determining whether the person operating the 
activation terminal is authorized to operate the 
activation terminal and, if the person is 
authorized, adding the value to a balance stored in 

20 a database entry associated with the prepaid card; 

e. reading the prepaid card, including identifying 
information, at a clerk terminal; 

f . entering at the clerk terminal a value to be 
redeemed from the prepaid card; 

25 g. sending to the host computer (i) information 

identifying the prepaid card, (ii) the value to be 
redeemed from the prepaid card, and (iii) 
identification information associated with a person 
operating the clerk terminal; 

30 h. subtracting the value to be redeemed from the 

prepaid card from the balance stored in the 
database entry associated with the prepaid card if 
(i) the person operating the clerk terminal is 
authorized to operate the clerk terminal and (ii) 

35 the balance in the database entry associated with 

the prepaid card is greater than or equal to the 
value to be redeemed. 
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16. The method of claim 15 further comprising the steps of: 
a. reading at a manager terminal a manager card 

identification number from a manager card; 
5 b. entering at the manager terminal a manager terminal 

operation; 

c. entering at the manager terminal identification 
information associated with a person; 

d. sending to the host computer the manager card 
10 identification number, the operation and the 

identification information associated with the 
person; and 

e. determining whether the manager card identification 
number is from an authorized manager card and, if 

15 so,, updating information in the database, based on 

the entered operation, regarding whether the person 
having the entered identification information is 
authorized to use certain activation, clerk and 
manager terminals. 

20 

17. The method of claim 16 where the operation is to 
authorize the person having the entered identification 
information to use certain activation, clerk and manager 
terminals . 

25 

18. The method of claim 16 where the operation is to remove 
authorization of the person having the entered 
identification information to use certain activation, 
clerk and manager terminals. 

3° 

19. The method of claim 16 where the certain activation, 
clerk and manager terminals are all activation, clerk 
and manager terminals in the same store as the manager 
terminal sending information to the host computer. 

35 

20. A method of processing prepaid card transactions 
comprising the steps of: 
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a. connecting a workstation to a host computer wherein 
the host computer can access a database storing 
information regarding prepaid cards and terminals 
for performing prepaid card transactions; 
5 b. determining access rights of a user at the 

workstation to the information in the database, 
including 

(1) whether the user may increase a current 
balance associated with one of the prepaid 

10 cards; 

(2) an amount the user may add to the current 
balance associated with one of the prepaid 
cards in a single transaction; and 

(3) a total amount the user may add to the current 
15 balance associated with one of the prepaid 

cards over a specified period of time. 

21. The method of claim 15 further comprising the step of 
sending terminal identification information to the host 

20 computer and wherein the steps of determining whether 

the persons operating the activation and clerk terminals 
are authorized comprises, for each such person, locating 
a database entry associated with the received terminal, 
the database entry specifying a list of persons 

25 authorized to use the terminal, and determining whether 

the person operating the terminal is on the list of the 
authorized persons. 

22 . The method of claim 15 wherein the steps of adding the 
30 value to the balance and subtracting the value to be 

redeemed from the balance further comprise, for each 
transaction, storing transaction information comprising: 
a. information identifying the terminal at which the 

transaction was initiated, 
35 b. information identifying the person operating the 

terminal ; 
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c. information identifying the prepaid card whose 
balance was modified; 

d. an amount of the transaction; and 

e. a type of the transaction. 

5 

23. The method of claim 15 further comprising the steps of 
a. determining a list of sales representatives 

entitled to commissions for transactions occurring 
at the activation and clerk terminals, 

10 b. determining commissions owed to the sales 

representatives on the list of sales 
representatives and to an operator of the host 
computer, and 
c. paying the commissions from a specified account 

15 associated with the terminals. 

24. The method of claim 23 further comprising the step of 
storing, for each transaction for which a commission is 
owed, information regarding whether the commission has 

20 been paid from the account. 

25. The method of claim 15 further comprising storing in the 
database entry associated with the prepaid card the 
number of times the card has been used. 

25 

26. The method of claim 15 further comprising storing in the 
database entry associated with the prepaid card a bonus 
point total derived from the use of the card and a 
redeemed point total indicating the number of bonus 

30 points that have been redeemed. 

27. The system of claim 26 wherein the bonus point total is 
the total dollar amount of transactions in which the 
card was used to purchase goods and services. 

35 
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28. The system of claim 1 wherein a set of the one or more 

prepaid cards is for prepaying for a service billed on a 
periodic basis. 

5 29. The system of claim 1 wherein a set of the one or more 
prepaid cards is for prepaying for prepaid local 
telephone service. 

30. A prepaid card system for prepaying for a service billed 
10 on a periodic basis comprising: 

a. one or more prepaid cards each having an associated 
account number; 

b. at least one activation terminal at which value can 
be added to the one or more prepaid cards; 

15 c. a computer associated with a provider of the 

service; 

d. a host computer that can communicate with the at 
least one activation terminal and the provider 
computer; and 

20 e. a database that can be accessed by the host 

computer wherein the database stores 
i) for each of the at least one activation 

terminals, information regarding each clerk 
authorized to use the terminal; 
25 ii) information regarding access rights of users 

of the provider computer to information in the 
database ; and 
iii) for each of the one or more prepaid cards, a 
current balance associated with the prepaid 
30 card and information regarding the prepaid 

service. 

31. The system of claim 30 wherein the prepaid service is 
prepaid local phone service. 

35 
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32. A method for processing prepaid transactions for a 

service billed on a periodic basis comprising the steps 
of: 

a. reading a prepaid card, including identifying 
5 information, at an activation terminal ; 

b. entering at the activation terminal a value; 

c. entering at the terminal a product code; 

d. sending to a host computer (i) the card identifying 
information, (ii) the value, (iii) the product 

10 code, and (iv) identification information 

associated with a person operating the activation 
terminal; and 

e. at the host computer, 

(1) determining whether the person operating the 
15 activation terminal is authorized to operate 

the activation terminal; 

(2) if the person operating the terminal is 
authorized, locating a database entry 
associated with the prepaid card, the database 

20 entry storing a balance; 

(3) determining a price associated with the 
product code, and 

(4) determining whether the received value plus 
the balance is greater than or equal to the 

25 price and, if it is, adding the value to the 

balance in the database entry and storing 
information regarding the product code in the 
database entry. 

30 33. The method of claim 32 further comprising the step of: 

sending to a computer associated with a provider of 
the service the card balance and the information 
regarding the product code and setting the card 
balance in the database entry to zero. 



35 



34. The method of claim 33 further comprising the steps of: 
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a. determining at the provider computer a price 
associated with the received product code 
information; and 

b. sending a message from the provider computer to the 
5 host computer instructing the host computer to 

credit the balance associated with the card if the 
price determined by the provider computer exceeds 
the balance received by the provider computer. 

10 35, The method of claim 32 wherein the product code 

specifies an initial activation of the service and 
further comprising the steps of: 

a. providing, by a customer to a representative of the 
provider, information regarding the card and 

15 customer information required for activating the 

service; 

b. connecting a computer associated with the provider 
to the host computer and determining whether the 
representative is authorized to access information 

20 regarding the card; and 

c. if the representative is authorized, sending to the 
provider computer the card balance and the 
information regarding the product code. 

25 36. The method of claim 32 wherein the service is prepaid 
local phone service. 



30 



35 



- 39 - 



WO 00/50986 PCT/US00/04654 

1 / 13 




2 / 13 



PCT/USOO/04654 




WO 00/50986 



3 / 13 



PCT/US00/04654 




CO 
LL 



WO 00/50986 PCT/US00/04654 

4 / 13 



V) 


c 












<D 


g 








c 




CL 


CO 








o 




>* 






















o 




1 










CO 


c 


c 


o 








ui 


o 


o 


< 


o 






C 








S> 




"O 


CO 


Q. 


o 

CO 


CO 


CO 


c 


CO 
t— 


st Tr 


E 


ns 


c 


_c 
o 


tur 


O 


CO 

x> 


2 


O 


CO 


CO 


CO 


CO 


CO 




cc 


a: 


o 


1- 


0£ 






CM 


CO 






CD 



WO 00/50986 



PCI7US00/04654 



5 / 13 



82 



No 



Send "NO* to 




72 



Select Add or 
Delete Clerk 
Operation 



74 



\ 



Enter Clerk No 
(Password) 



76 



N 



Host redeves a 
can from a terminal 




-No- 



Yes 



86 



Fig. 5 



Add/Delete 
Clerk # 



WO 00/50986 



6 / 13 



PCT/US00/04654 




WO 00/50986 



7 / 13 



PCT/USOO/04654 



132* 



Select 



130* 



Swipe 
Card 



Enter 
Value 



135T 



Clerk No 



136^ 



Host recieves a 
catl from a terminal 



138^ 




144 



Send "INVALID 
TERM" to the 




150 



152* 



Send -DECLINED" 
to the terminal 



Yes 



154 -^V 
/ Is there \ 

<^ sufficient ^> 1 

\babnce?/ 



156* 



Send "NSP & 
avail balance to 
the terminal 



158 



Yes 



Send "OK" & Avail. 
Balance to the 



sXM the terminarv Ma — » 



Hangup 



Fig. 7 



Debit amount from 
card number In the 
D8 

64 



WO 00/50986 



8 / 13 



PCT/US00/04654 



Connect to Host via Dial up, 
Dedicated Une or Internet 




Rg. 8 



WO 00/50986 



9 / 13 



PCT/US00/O4654 



220- 



Card Holder Calls 
Customer Service 




Get 
$ Balance 



Find Closest 
Location 



224- 



226- 



228 -^1 



Call to 
Customer 
Service Rep 






230 








Transactions 




232 






Issue Credits 




234^ 






Add Notes 



Fig. 9 



WO 00/50986 



10 / 13 



PCT/USOO/04654 



Fig. 10 



250- 



Set Current Entry to first 
Transaction Table Entry 




Get commission owed by 
merchant from rates table 



Yes 



Withdraw commission from 
merchant's bank account 



260 



Calculate commissions 
owed to tales 
representatives and 
subrepresentatives 



262 



Set current entry to next 
transaction table entry 



No 




WO 00/50986 



PCT/OS00/04654 



11 / 13 



Enter 
Product Code 



Swipe Card or 
enter homo 



Select 
Activate 




Enter 




Enter 
Clerk No 




Value 





Host receives e 
can from a terminal 




Transection 
Type 




WO 00/50986 



12 / 13 



PCT/USOO/04654 



<D 
<D 
U_ 
+-» 
c 

CD 

e 
>, 

CO 
OL 



O) 

c 

"2 

CO 



c 

"co 
O 
>» 

CO 



CD 



c 
o 
"</> 
c 

Q> 
Q. 
05 

CO 

I— 

<D 
JC 
CO 

c 
o 

(0 

o 

CO 

© 



CO 

o 

CO 



o 



c 
E 

CO 

e- 

> 

o 



CM 
1 — 



WO 00/50986 



13 / 13 



PCT/US00/04654 




2 5 
I O .2 

£ Q.T3 10 -D 



CM 



CO 

CD 

LL 




INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/USOO/04654 



A. CLASSIFICATION OF SUBJECT MATTER 

EPC(7) :G06F 15/24, 7/12; A63F 9/24 
USCL :364/405; 235/380, 375 
According to International Patent Classific ation (IPC) or to both national classification and IPC 

B. FIELDS SEARCHED ; 

Minimum documentation searched (classification system followed by classification symbols) 

U.S. : 364/405:235/380,375 
Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 
EAST 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Citation of document, with indication, where appropriate, of the relevant passages 



US 4,589,069 A (ENDO ET Al.) 13 May 1986 (13/05/1986), see 
entire document. 

US 5,770,533 A (FRANCHI) 23 June 1998 (23/06/1998), see entire 
document. 



Relevant to claim No. 



1-36 



1-36 



| | Further documents are listed in the continuation of Box C. See patent family annex. 



Special categories of cited documents: 

document defining the general state of the art which is not considered 
to be of particular relevance 



published on or after (he international filing date 

document which may throw doubts on priority diixn(s) or which is 
cited to establish the publication date of another citation or other 
special reason (as specified) 

document referring to an-eral disclosure, use, exhibition or other 
means 

document published prior to the international filing date but later than 



later document published after the international filing date or priority 
date and not in conflict with the application but cited to understand the 
principle or theory underlying the mvcntion 

"X" document of particular relevance; the chimed invention cannot be 

considered novel or cannot be considered to involve an inventive step 
when the document is taken alone 

"Y" document of particular relevance; the claimed invention cannot be 

considered to involve an inventive step when the document is 
combined with one or more other such documents, such combination 
being obvious to a person skilled in the art 

document member of the same patent family 



the priority oate ciaunea 

Date of the actual completion of the international search 
24 APRIL 2000 


Date of mailing of the international search report 

tMauoMrC) — ti 


Name and mailing address of the ISA/US 
Commissioner of Patents and Trademarks 
BoxPCT 

Washington, D.C. 20231 
Facsimile No. (703) 305-3230 


Authorized officer / [ 7; l^ty I 

DOUGLAS X. RODRIGUEZ 1 _y ' 
Telephone No. (703) 308-408 1 



Form PC17ISA/210 (second sheet) (July 1998)* 



